[t:/]$ 지식_

cuda string search

2018/09/20

cuda 맛보기로 간단한 문자열 카운터를 만들어보았다. 1070에 unified memory를 쓰고 file backed mmap으로 따낸 포인터를 attach했다. 문서들을 보면 pascal부터 unified memory는 page fault든 copy on write든 동적상황에 따라 메모리 복사를 잘 뽑아서 성능이 괜찮다는 것 같다. 옛날처럼 host, device 메모리 관리한다고 품 많이 안 들고 걍 대충 쓰면 적당히 빠르다는 느낌이라 그냥 unified로 써봤다.

결과는 host only로 동작시키는 것 보다 꽤 느리다. 뭐 당연하다면 당연한 것인데 문자열 검색 비용은 작고 dma든 뭐든 메모리 복사 비용이 크다는 것이다. gpu에 의해 SIMT 쓰레드 512개를 설정해도 꽤 느렸다. 수치를 적지 않는 것은 프로파일링 결과마저도 들쭉날쭉 하기 때문이다. host only 실험의 일률적인 결과와는 많이 다르다. 실험을 위해 조건 통제를 어떻게 할 수 있는지는 아직 모르겠다. nvprof에 의한 gpu구간의 성능을 보면 hostregister할 때 시간을 다 쓰고 있다. 시퀀설 탐색인 관계로 이 때 그냥 memcpy를 다 뽑는 것 같다. memadvice류로 뭔가 hinting을 주어서 readahead를 시도해 볼 수도 있을 것 같긴 한데, 그간의 이런저런 경험에 따르면 비관적이다. 호스트에서는 예전에 해볼만한 실험을 다 해봤다. 랜덤 액세스 처럼 나눠서 할 수도 있을 것 같긴 한데 GPU 메모리보다 큰 파일에 대해 어떤 식으로 동작할지는 의문이다. GPU 메모리보다 더 큰 어드레스 공간은 넣고 빼고 쑈를 하거나 아예 등록이 안 될 것 같은데 나중에 실험해봐야겠다.

어쨌든 IO비용에 비해 GPU 구간의 속도는 거의 us단위로 처리되고 있는데, 문자열 검색의 복잡도가 올라간다면 이것은 노려볼만 하다. 즉, 큰 사전을 검색한다고 가정하면 그렇다. 파일 크기가 같다면 IO비용은 고정이다. 그 다음 부터는 SIMT 비용이다. 이것은 매우 빠르다. 문자열 1000개를 찾아라! 이런 문제에 대해서는 유리할 것 같다.

추가

GPU 메모리보다 큰 파일을 우겨넣으려고 했더니 역시나 에러가 난다. 쓰고 빼고 하는 작업을 손으로 해야 할 듯... 나의 바람은 어드레스 공간은 등록이 되고, page-fault와 eviction rule에 의해 넣고 빼고 알아서 해주는 것이었던 것이었던 것이었다..





공유하기













[t:/] is not "technology - root". dawnsea, rss